Motivating Contributors and Their Managers
Group Session: Motivating Community Members (and Managers) to Contribute ---- Attendees * Kara Sowles – Puppet Labs – Community Coordinator * Jacob Greer – Freelance – Freelance * Angela Oduor – Ushahidi – Community Developer Liaison * James Falkner – Liferay, Inc. – Community Manager (Organizer/Note Taker) * Federico Lucifredi – Canonical Usa – PM * Kristina Hoeppner – Catalyst It – E-Learning Specialist * Richard Esplin – Alfresco Software – Community Technology (Note Taker) * Eric Schultz – Outercurve Foundation – Developer Advocate Goal Understand and discuss typical reasons why companies do not contribute, and come up with responses on the benefits of getting involved in the open souce projects on which they depend. Observations Many potential open source contributors to Liferay do not contribute because they cannot - their employers either do not let them outright, or make it clear that it is not to be done while on “company time”. Top reasons given include: Contribution or participation in external OSS projects is considered not ‘core’ to company business - does not contribute to bottom line. Knowledge, skills, and code written ‘on the clock’ belong to the company, and could potentially reveal company secrets (“secret sauce”) which would be detrimental to the company if freely given to competitors. Many companies don't understand open source. They do amazing things, but don't want to give back. Discussion Why don't they contribute back? -- Proposed solution / counter-point Don't want employees working on "pet projects" on company time--not billable / not a task -- You depend on open source, you should contribute back -- Over time, you can help the ones that contribute to grow (recruit, get customers) Client doesn't want contributions to be sent back--worried about competitive advantage -- List advantages of contributing back (someone else maintains) -- Point out that the code probably isn't a competitve advantage (SI is probably reusing code anyway) Bryan Cantrill (Joyent), open source anti-patterns: worry about competitive advantage (your competitors would rather fail then adopt something that you invented) (Slides , Video at 35:00) *Contributing back results in reputation in the community *Not contributing back just prevents people from helping you. *Stop spending coporate Organizations might not be able to contribute a bug fix or a feature, but might make other contributions: * Documentation * Polish * Testing * Code review * Helping on the forums Helping in the forums is a form of free support. Would otherwise be able to charge for that assistance * Helping people builds reputation * When people ask for help, it isn't the little stuff it is the larger, interesting (and costly) questions * Results in better customer satisfaction and higher renewal rates * Maybe stack exchange is a closer fit to US culture as oppossed to EU culture * Helping in the forums is a forum of free training When most open source users contribute back, their companies have no idea. * How to encourage them to contribute back more? -- Without distracting them from their core job * Some contributors need special permission to be recognized *: company doesn't want to be a case study *: management might not know how much time is spent contributing Engineering question: Make the product easier to build an package an integration. * Goal is to make a contribution take less than 2 hours * Create a different IRC channel for up-and-coming contributors to give them special attention. * Issue tracker priority for "bite-sized bugs" that take less than 2 hours. Ubuntu 100 paper cuts project. Kernel janitor project. Mentored bugs program. * Banner / button that rotates an easy bug to fix * openhatch Work harder to involve non-developers. Often times willing to contribute, but don't know they can contribute. * Often times gain ability to make more technical contributions Koha-community.org : Excellent example of "how to contribute" including an automated script to produce a sand box to test a big How to get the message into the companies that need it: * Changing minds often requires a personal conversation: sales call, event * Company brand as a chance to share open source culture * Send open source happy t-shirt * Reward those that do contribute, and make sure they tell the company why they were recommended Training advantages: * Learn how to collaborate with a global team * Learn how a large project works. Some managers/employers have this outlook: You need to have client time that does contribute to the bottom line (both code and discussion). Therefore, any time spent doing anything else does not help. Also, many clients that pay for services rendered feel that those services (and the resulting code) directly relate to their business and do not want others to get that “for free”. Counter-argument: contributed code is code that clients and SIs (system integrators) do not have to maintain themselves, thereby saving money, and contributing to the bottom line. It also takes a bit of a leap of faith to believe that short term loss (in terms of time spent contributing) has long term benefits, that are difficult to see immediately. e.g. you help someone “for free” by giving them a solution, and later they may come back to you and buy your for-pay services because you helped them “for free” earlier. Some jobs are mainly cookie-cutter, and do not involve a lot of customization. SIs typically re-use the tech on other jobs, and don’t want to just hand that hard-won tech over to competitors. Some of us who use the open source components don’t want competitive aspects. Statement: Most companies that think things are secret sauce are not. However, if they truly examine what it is about their tech that they think that it is so core to the company, they in most cases find that it is not, and even if a competitor had it, would not be able to reproduce the value that the company brings through said tech. One benefit of contribution from companies is that it builds the company’s and individual reputation, which might win future business. BUT: some companies simply do not care about reputation, and have no desire to (and there is no benefit to) being “experts” in a particular OSS tech. The argument here is that even if you don’t care about reputation, participation in open source builds your own internal expertise, by essentially “free training” of employees. You don’t necessarily have to contribute code, but just get involved. Other motivations include offering unique privilege to customers, for example giving free speaking slots at conferences to contributing/participating companies, and using this as a carrot to get them to do more. Observation: bigger companies (or small companies with bigger engineering staff) tend to contribute more because they have more padding, more room to fail. They don’t disappear in a year because they “contributed too much”. It’s a fallacy, but a reality that many companies feel this way. Most bigger companies have policies in place for external participation/contribution which is good for even small companies. Contributions are considered more than just source code (e.g. forum participation, translations, documentation, etc). and this can prevent users from contributing back because they don’t have technical skills and don’t know “how” to contribute non-code contributions. Another way to convince reluctant companies who fear giving out “free support” to non-paying users: You can save money by answering easy questions, because then you have more time to tackle more interesting questions later by your support team. You are seen as the good guy. Teach your customers/community to fish, rather than giving them the fish you already caught. In that light, empowering to be self-sufficient is seen as a bonus, not a detriment. Quality of forums directly relates to satisfaction and renewal rates. If you have a healthy forum and community, customers who are up for sales or renewals will evaluate this (or at least their engineers will, and communicate this to decision makers, if they themselves are not the decision maker!). Interesting how contributors fit different models. US doesn’t contribute to forums, but does great work. EU understands that forums are customer satisfaction and seek to maximize their potential by contributing. Observation: many companies don’t “know” that their employees are contributing. In a lot of cases employees can find that balance themselves, so if you notice this, then you can use it to attract even more contribution from said company. Observation: in young open source projects, it’s much easier to contribute: there is a basic architecture, but many missing blanks to be filled in from a range of technically savvy developers or novices alike. As projects mature and get a lot more implementation/experience, it becomes much harder to develop. As OSS project leaders, we must fight this (some examples from another session include focusing on modularity, keeping the development cycle short, and other tips). A priority of companies should be that it should be easier to add-on/package, which means its easier to contribute. More modularity means more insulated code, easier for beginners to grasp what they need to do without collateral damage. Question to Kara: sometimes if some developers just contribute back without their companies know knowing, how does that work with IP/license issues? A: contributors sign a CLA but tend to know the line to walk. How to motivate contributors? Alfresco: at our last summit: our top 4 contributors had no tech skills at all at the beginning, and quickly became rock stars. This was surprising. Others: at some conferences, where there are hackfests, we showcase up and coming developers. We have tools that can automate the onramping, e.g. a web form: type in a patch #, and it grabs and creates an environment for you, applies the patch, and leaves you to test it. How do you find people who are using your OSS product that you want to get contributions from? You must know your community, and many struggle with knowing about the community. If you have un and coming contributors, and you can’t fix the issue on IRC, point them at a different channel. Simple bugs (byte-sized bugs) are good to have, for beginners. e.g. Ubuntu’s or Liferay’s 100 PaperCuts program. Another project put a rotating banner of “novice bugs” on the front page to attract new developers. For the kernel (Linux) - there is a project called ‘kernel janitors’ that does precisely this. Here’s an interesting outlook on NDAs: why do you require them? You’re just preventing people from helping you. There’s a similar point: in banking/finance, certain type of software are shared in their own particular communities, and they are all competitive, but they undertsand there is no competitive advantage to sharing “non-critical” code. Another example of this is Google: well-respected pro-open source company that does a lot to further the cause, but their core code (search algorithm) is NOT open source. How do you help someone who is struggling with their company or the individual worried about the above issues when they wish to contribute? You have to talk to them: either call them up and find a way to talk with the boss, take to lunch, attend a call, etc. the other is to just have that culture that when you have an event, you get a chance to indoctrinate a bit. Be persistent about your message of contribution and OSS: the longer you use product, the more you start to understand. Publish as a cheat-sheet to hand to partners. Summary The goal of this discussion was to develop a list of typical arguments against OSS contribution, and a corresponding response. Argument: It’s not core to the company’s bottom line / core business Counter-argument: *By participation and contribution to OSS, company is seen as the “go-to” entity for that technology, helping future sales opportunities *Employees get essentially “free training” in multi-cultural, global teamwork, and on technology that IS core to the business. *You end up teaching a community a volunteers a little about your business, and you might be surprised at what ideas it (the community) collectively has that you would never have thought of *The code and knowledge you contribute is expensive to maintain. By contributing it “upstream”, you no longer have to maintain that, or deal with it during upgrades. You save lots of support costs. *You (as a company) can get ancillary benefits like speaking slots at conferences *Have general guidelines or policies in place for employees to follow Argument: 'Don’t want to give away our company secrets (secret sauce). '''If we spent 5 years developing a repeatable, reusable client engagement tool, why would we want our competitors to have that for free? ''Counter-argument: *Unless you are runing a charity, you should never give away your secret sauce. The hard, but valuable part is identifying what really is your secret sauce, and contributing in areas outside of that. Observation: Your competitors would rather fail than adopt your strategy or use your solution (see video/presentation above) So even if you did publish your secret sauce, your competitors would ignore it - after all, they are better than you anyway, right?